This approach may yet turn out to be unworkable, but I'm going to keep plugging away at it. The basic idea is that server.js becomes app/server.js, the entry point for a bundle that includes a generated manifest that gets passed to the middleware, rather than everything happening behind the scenes. Similarly, templates/main.js becomes app/client.js, and imports the routes from a generated manifest file.

A number of things follow from this design decision:

• App structure is more explicit and internally consistent. For example, app/server.js and routes/foo/bar.js are part of the same bundle, and can use the same modules (say, something that manages credentials). Everything goes through the bundler, so you can e.g. use TypeScript and ESM everywhere
• File-watching is no longer the responsibility of the Sapper middleware. Instead, the entire server is shut down and restarted when it changes. This means there needs to be a new CLI command — sapper dev, perhaps — responsible for coordinating all that
• This makes certain things a little tricky — we can't inject our own monkey-patched fetch implementation to use in sapper export, for example, because the server needs to run in a child process controlled by the CLI. (I suspect the answer will be to process.send middleware responses to the CLI.) Also, I currently have no idea how hot module replacement will work

As part of these changes, there will be a single page template file — app/template.html — and 4xx and 5xx responses will use routes/4xx.html and routes/5xx.html components. There is also now a webpack config for app/service-worker.js (if you have one), so all the webpack config now sits in its own directory.

There'll need to be a migration guide from 0.6 to 0.7, as I don't think sapper upgrade will suffice.